「原來 ng serve 裡有這麼多學問阿？！真是長見識了！！那我們該如何交付我們的程式或是將我們開發出來的程式放到網路上呢？直接把整個專案資料夾放進空間裡嗎？」Wayne 喃喃自語後問道。
「當然不是阿！這時候我們要下另外一個叫做 ng build 的指令讓 Angular CLI 幫我們做事。我跟你說 ...」
的確，以前的前端的確就是將我們開發時的程式碼直接放上空間或交付給後端人員處理即可。但隨著前端技術以及工具的發展，現在的前端所開發出來的程式碼也已經大多都需要透過工具的編譯，瀏覽器才能看得懂。
使用 Angular 所開發出來得應用程式當然也是需要經過編譯之後，瀏覽器才能看得懂，所以 Angular CLI 當然也有提供指令讓我們可以很輕鬆地就將檔案編譯並打包出來，那就是： ng build 。而編譯出來的檔案會放在根目錄的 dist 資料夾內。
同樣地，ng build 也有許多參數可以使用。如：
--prod － 將會使用 Production Mode 來編譯與打包專案。
--source-map － 打包出來的檔案會含有 source map 的檔案 （不知道什麼是 source map 的朋友可以參考保哥的文章） 。
那所謂的 Production Mode 跟 Normal Mode 差別在哪呢？用我們之前做的 MyMessageBoard 專案來舉例說明，先從 Normal Mode 開始看起：
上圖是 Build 完之後，在 dist/MyMessageBoard/ 裡的所有檔案。
上圖是在 dist/MyMessageBoard/ 裡， main.js 檔的大概長相。
上圖是 Build 完之後，在終端機上的 Log。
上圖是 Build 完之後，dist/MyMessageBoard/ 這個資料夾的大小。7.1MB，還滿大的！
看完 Normal Mode 之後，我們再來看使用 Production Mode 之後會變成什麼樣子：
首先是檔案的部份，除了因為沒有下 source map 的指令，所以沒有 source map 的檔案之外，也少了 vendor.js 這個檔案。另外檔名的部份多了一些看似亂碼的東西，其實那是該檔案的 hash 值。
為什麼要在檔名加上 hash 值呢？！其實主要是因為瀏覽器的 cache 機制的關係，至於詳細可以參考此篇文章，我覺得裡面寫得非常好也非常詳細，我就不再畫蛇添足、畫虎不成反類犬了。
接著我們同樣打開 main.XXXXXX.js 的檔案來看看：
阿這一沱是蝦米東東？
這是因為 production mode 會幫我們把編譯出來的程式碼全部經過 Uglify 與 Minify 的處理，把檔案的內容縮減到最小，讓瀏覽器在下載檔案的時候可以更快下載完，程式碼也會有個基本的防護。
至於 Log 的部份：
可以很明顯地看出來檔案小了很多。
整體大小從 7.1MB 降到只剩下 302KB，我的老天爺阿！這是怎麼做到的阿？！
謎之音：娘子，跟牛魔王出來看上帝。
其實這是因為 Angular CLI 在 Production Build 時，做了以下這幾件事：
Tree-Shaking 機制 － 把專案中沒有用到的功能透過此機制過濾掉，就像在搖樹一樣，會把已經乾枯或已經死掉的葉子給搖掉。
上述有提到過，透過使用 UglifyJS 來將編譯出來的 js 達到最小化。
採用 AOT （Ahead-of-Time，事先編譯） 的機制來編譯程式碼。
一般來說，Angular 是採用 JIT （Just-in-Time，即時編譯） 的機制來處理我們的程式碼。意思是當瀏覽器載入我們編譯出來的程式碼之後，Angular 會在程式碼運行的時候，即時編譯我們的程式碼，然後開始運行我們的應用程式做出相應的動作。
但 AOT 是在 Angular CLI 在編譯我們的程式碼的時候，就先將所有 Angular 的程式編譯完，所以瀏覽器在載入我們編譯出來的檔案時，Angular 不需要再編譯我們的程式碼，也不需要將編譯相關的程式碼打包進去，效能變好、檔案變小。
而且我覺得很重要的一點是，採用 AOT 的方式編譯，會讓你的程式碼至少在格式以及語法上不會有問題。因為事先就編譯好的關係，所以如果在格式或語法上有任何問題的話，編譯就不會通過，降低錯誤發生的機率。
當然 ng build 不會只有這兩個參數而已，只是我覺得這兩個參數大致上就能包含我想講的內容，其他的大家就請參考官方的 Wiki 吧！
iThome鐵人賽
看影片追技術